To accurately model a person's or a family's financial plan requires managing a large number of variables. For example, to create a financial plan that is meaningful, the user needs to provide a lot of current information such as salary, debt and savings, and also needs to specify many future financial events, such as paying for a child's college education, getting a raise, contributing to a savings plan, and retiring. Present financial planning software uses the input information to develop a financial plan, typically by running a simulation with the input information and outputting whatever results.
Many financial events may be dependent on other financial events. For example, a user may plan to buy a boat as soon as a car is paid off. Although such a relationship is implicitly understood by a user, financial planning software does not capture these relationships. Although a few easily predictable relationships may be hard-coded into the software of a financial plan, usually the only way for a user to define these relationships in is by typing dates and/or amounts for one variable that are the same as dates and/or amounts on variable. For example, a user may enter, “Sell Current House in May, 2000” and then later enter “Buy New House in May, 2000.”
There are two main problems with this approach. A first problem it that this approach makes it cumbersome to create the financial plan, because the user must be diligent about entering exactly the same dates and/or amounts on separate variables. Secondly, after a first draft of the plan is created, it is difficult to make changes to the plan because the user must manually maintain the implicit relationships between objects. Using the above example, if the user changed the sale date of Current House to July, 2001, the plan would be inaccurate until the user remembered to also change the purchase date of New House. As can be readily appreciated, more complex events such as retirement (e.g., wherein income and contributions to a savings plan cease, monthly commuting expenses change, and so forth) may require concurrent updates to many variables, of which even a careful user can easily lose track.
Moreover, present financial planning software does not make it easy for the user to see the impact of removing a financial event from their plan. For example, to see how much sooner a user could retire if the user sold a vacation home requires the user to delete an object that stores the vacation home information, run a new simulation, and then manually reconstruct the vacation home object if the user preferred the plan as it was before. If any variable information depends on the deleted object, such as monthly payments being made on the vacation home, the user must take this into consideration as well.
Still another drawback to existing financial planning software is that it is separated from the user's real day-to-day financial transactions, even for users that use an electronic “checkbook” type of software program for tracking day-to-day transactions. For example, if the user gets an unexpected bonus and pays off credit card debt with the bonus, the user has to separately input the new information into the electronic checkbook as well as the planning software. The planning software thus relies on the user to make appropriate updates, which tends to make a financial plan quickly outdated for many users. This is true even for things that seem relatively minor, as, for example, compound interest over a long time can amplify the effect of even what seems to be a relatively small transaction.